Generally, when an information processing apparatus is started, the process of recognizing connected devices and enabling access to the individual recognized devices is performed prior to the execution of an OS (Operating System) program. The UEFI (United Extensible Firmware Interface) is known as one of specifications defining the procedure for enabling access to devices prior to the execution of the OS.
After powered on, an information processing apparatus complying with the UEFI specification loads, from its storage device, startup management firmware for performing the function called “boot manager”, and executes the startup management firmware. In accordance with the startup management firmware, the information processing apparatus loads, into its main storage device, programs called “UEFI drivers”, which are associated with respective devices connected to the information processing apparatus. The UEFI driver is a driver program describing the procedure for controlling a device associated therewith and is loaded, for example, from the same storage device as that storing the startup management firmware or from a storage area provided in the associated device.
In the following description, the expression “UEFI driver” designates the “boot service driver” as provided by the UEFI specification. The boot service driver is used before the start of the OS program and is not used after the OS program is started.
In accordance with the UEFI driver loaded into the main storage device, the information processing apparatus executes an initial setting process using the loaded UEFI driver. The initial setting process using a UEFI driver includes, for example, inspection as to whether or not the UEFI driver supports the device to be controlled, initialization of the device, and initialization of control data used in controlling the device.
Where the initial setting process using a UEFI driver has normally been completed, access to the corresponding device can be controlled by using the UEFI driver. For example, after the initial setting process using the UEFI driver is completed, the information processing apparatus calls a UEFI driver associated with a desired device in accordance with the startup management firmware, and reads out an OS boot loader from the corresponding device in accordance with the called UEFI driver. The information processing apparatus then executes the OS boot loader thus read out, to initiate the process of starting the OS program.
As an example of computer systems having the function of monitoring anomaly during the execution of programs, a computer system has been known in which the startup time for the OS program and the execution period of each program are monitored by respective independent timers and the computer system is reset depending on the logical sum of overflow outputs from the timers. In another exemplary computer system, when the computer system is restarted due to the occurrence of fault during the execution of the OS program, the OS is booted using a memory area different from that used before the restart so that the memory information dumped at the time of occurrence of the fault can be reliably saved.
Also, in connection with techniques wherein a startup program (BIOS: Basic Input/Output System) is selected from among those stored in a plurality of flash ROMs (Read Only Memories), a computer has been known in which the correctness of the startup program is determined and the startup program to be selected is changed depending on the result of the determination.                Japanese Laid-open Patent Publication No. 2002-189615        Japanese Laid-open Patent Publication No. 2006-72931        Japanese Laid-open Patent Publication No. 2003-316582        “Unified Extensible Firmware Interface Specification Version 2.2”, Unified EFI, Inc., September 2008, pp. 15-19 and 304-313        
The policy for the startup management firmware according to the UEFI could be one of the following two policies: The first policy is to perform the initial setting processes by using UEFI drivers associated with devices which are necessary and sufficient for starting the OS program, to make these devices ready for use. The second policy is to perform the initial setting processes by using UEFI drivers associated with as many devices as possible, among the devices connected to the information processing apparatus, to make the devices ready for use.
The second policy is very often adopted in high-versatility apparatus such as servers in which various devices are possibly connected or the OS program to be executed can be selected from among those stored in a plurality of devices. The reason is that in the case of high-versatility apparatus, the number and kinds of connected devices may vary each time the apparatus is started, with the result that selectable devices from which the OS program to be executed is read out also vary from time to time.
Where a UEFI driver containing an anomaly occurrence factor, such as a bug, is executed, the information processing apparatus fails to normally complete the execution of the UEFI driver. For example, when the initial setting process using such a UEFI driver is executed, the information processing apparatus may possibly fail to normally complete the initial setting process due to the bug contained in the executed UEFI driver. Also, even if the initial setting process is normally completed though the UEFI driver used contains a bug, it is possible that when access control is performed with respect to the corresponding device, the information processing apparatus is unable access the device or fails to normally complete the access control due to the bug in the UEFI driver.
Meanwhile, the UEFI driver (boot service driver), which is loaded by executing the startup management firmware, is not used after the OS program is started, as stated above. Thus, even if the execution of a UEFI driver associated with a device that has no involvement in the start of the OS program fails to be normally completed, the failure originally does not affect the process executed subsequently to the start of the OS program. The reason is that after the OS program is started, a device driver for the OS program, which is prepared separately from the UEFI driver, is used.
However, where the execution of a UEFI driver associated with a device that has no involvement in the start of the OS program fails to be normally completed, a problem arises in that the process fails to be continued through to the start of the OS program, regardless of whether the device with which the executed UEFI driver is associated has involvement in or no involvement in the start of the OS program. For example, where the process of the information processing apparatus stops during the execution of a UEFI driver and thus the information processing apparatus is restarted upon detection of the stoppage of the process, the process of the information processing apparatus again stops during the execution of the same UEFI driver. In such a case, the information processing apparatus is repeatedly restarted without the process being continued through to the start of the OS program. Also, where the process of the information processing apparatus stops during the execution of a UEFI driver and the process remains stopped without the information processing apparatus being restarted, the process naturally fails to be continued through to the start of the OS program.
The problem that “the process fails to be continued through to the start of the OS program where the execution of a UEFI driver associated with a device that has no involvement in the start of the OS program fails to be normally completed” is more likely to occur where the number of the UEFI drivers, which need to be made ready for use as programs for controlling access to the corresponding devices, is larger.
Further, the problem can occur not only in the information processing apparatus complying with the UEFI specification but also in other kinds of information processing apparatus in which driver programs associated with respective devices need to be made ready for use prior to the start of the OS program.